In the Linux kernel, the following vulnerability has been resolved:

mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()

copyhugetlbpagerange() clears the uffd-wp bit of migration and hwpoison entries with hugepteclearuffdwp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pteswpuffdwp() and pteswpmkuffdwp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.

No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADVHWPOISON on a 2MB anon hugetlb page shows:

offset before=120e00 offset after =120e02

The fallout is mostly latent: rmap walks match migration entries by folio range and removemigrationpte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlbchangeprotection() rewriting a writable migration entry via makereadablemigrationentry(swpoffset(entry)) -- propagates it.

Migration entries legitimately carry uffd-wp, so clear it with pteswpclearuffdwp(), matching copynonpresentpte() and movehugepte().

A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by makehwpoisonentry() (trytounmapone() does not preserve uffd-wp on the hwpoison path) and hugetlbchangeprotection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.

In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix missing metadata reservation for large xattrs

[BUG] lsetxattr() panics the kernel when setting a large xattr value on a fragmented filesystem where the file already has an external xattr block.

[CAUSE] ocfs2calcxattrsetneed() never reserves metadata blocks for a new xattr value's extent tree when the file already has an external xattr block. The notfound path leaves metaadd at zero, so metaac is NULL when ocfs2xattrextendallocation() runs.

A new value root has room for a single extent record. On a fragmented filesystem, the allocator cannot satisfy the xattr value in one contiguous run, so each non-contiguous run requires its own extent record. When the value root's extent list is full and metaac is NULL, ocfs2addclustersinbtree() returns RESTARTMETA, and ocfs2xattrextendallocation() hits BUGON(why == RESTARTMETA).

[FIX] The case where no xattr block exists yet already calls ocfs2extendmetaneeded(&defxv.xv.xrlist) to reserve value tree metadata. Add the same reservation to the case where an xattr block already exists, making the two cases consistent.

Replace the BUGON with a -ENOSPC return so that if RESTARTMETA is returned despite the reservation, the error propagates to userspace instead of panicking the kernel.

In the Linux kernel, the following vulnerability has been resolved:

hwmon: (pmbus/core) honor vrmversion in pmbusdata2regvid()

pmbusdata2regvid() hardcoded the VR11 encoding regardless of the vrmversion configured by the driver, while pmbusreg2datavid() already switched on it. Any driver that selects a non-VR11 VID mode and exposes a regulator (or hwmon vout setter) sent dangerously wrong codes to PMBUSVOUTCOMMAND -- e.g. an nvidia195mv part asked for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the chip interprets as 1080 mV.

Mirror pmbusreg2datavid() so writes round-trip with reads.

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xtconnmark: reject invalid shift parameters

Revision 2 of the CONNMARK target accepts user-controlled shift parameters and applies them to 32-bit mark values in connmarktgshift().

A shiftbits value of 32 or more triggers an undefined-shift bug when the rule is evaluated. Invalid shiftdir values are also accepted and silently fall back to the left-shift path.

Reject invalid revision-2 shift parameters in connmarktgcheck() so malformed rules fail at installation time, before they can reach the packet path.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: actpedit: fix TOCTOU heap OOB write in tc offload

There is a TOCTOU race condition in flower lockless approach between sizing a flowrule buffer and filling it. zdi-disclosures@trendmicro.com reports: The clsflower classifier operates with TCFPROTOOPSDOITUNLOCKED (flchange runs without RTNL), while RTMNEWACTION holds RTNL, so the independent locking domains make the race reachable in practice. KASAN confirms: BUG: KASAN: slab-out-of-bounds in tcfpeditoffloadactsetup+0x81b/0x930 Write of size 4 at addr ffff888001f27520 by task poc-toctou/312 The buggy address is located 0 bytes to the right of allocated 288-byte region [ffff888001f27400, ffff888001f27520) (cache kmalloc-512)

Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAPNETADMIN).

The fix introduces reading tcfpnkeys under act->tcfalock in all places using a new tcfpeditnkeyslocked() which replaces the old tcfpeditnkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than silently truncating the key count, which leads to incorrect action semantics offloaded to hardware and secondary OOB writes if the remaining capacity is zero or consumed by prior actions, we enforce remaining capacity checks and return -ENOSPC if the required space exceeds the remaining capacity.

In the Linux kernel, the following vulnerability has been resolved:

accel/amdxdna: Fix potential amdxdnaumap lifetime race

amdxdnaumaprelease() calls the blocking mmuintervalnotifierremove() before removing the object from abo->mem.umaplist. If aie2populaterange() runs concurrently, it may obtain a reference to an amdxdnaumap that is being released, leading to a potential use-after-free.

Use krefgetunlesszero() in aie2populaterange() when acquiring a reference. If the reference count has already dropped to zero, release is in progress and the entry is skipped.

In the Linux kernel, the following vulnerability has been resolved:

ntfs: fix mreclock ABBA deadlock in rename

ntfsfilefsync(), ntfsdirfsync() and ntfswriteinode() lock an inode's mreclock before taking the mreclock of its parent directory.

ntfsrename() takes oldni->mreclock and olddirni->mreclock before taking newni->mreclock for an existing target, or newdirni->mreclock for a cross-directory rename. This can deadlock when ntfsfilefsync() or ntfswriteinode() holds the target inode, or when ntfsdirfsync() holds a child target directory, while rename() holds the parent directory and waits for the target.

Fix this by locking the existing target inode before taking any parent directory mreclock. For cross-directory renames where the target parent is a descendant of the source parent, lock the target parent before the source parent so the directory order matches the child-to-parent order used by ntfsfilefsync(), ntfsdirfsync(), and ntfswriteinode().

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix potential buffer underflow in ath11khalrxmsdulistget()

When the first entry in msdudetails has a zero buffer address, the code accesses msdudetails[i - 1] with i == 0, causing a buffer underflow.

Fix similarly to ath12kwifi7halrxmsdulistget() by adding a separate check for i == 0 before the main condition to prevent the out-of-bounds access.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:

libceph: reject zero bucket types in crushdecode

CRUSH bucket type 0 is reserved for devices. The mapper relies on that invariant and uses type 0 to identify leaf devices.

If crushdecode() accepts a bucket with type 0, a malformed CRUSH map can make the mapper treat a negative bucket ID as a device and pass it to isout(), which then indexes the OSD weight array with a negative value.

Reject zero bucket types while decoding the CRUSH map so the invalid state never reaches the mapper.

In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - validate RSA CRT component lengths

The generic RSA key parser (rsahelper.c) bounds each CRT component (p, q, dp, dq, qinv) by the modulus size nsz, but qatrsasetkeycrt() allocates half-size DMA buffers (keysz / 2) and right-aligns each component with:

memcpy(dst + halfkeysz - len, src, len)

When a CRT component is larger than halfkeysz the subtraction underflows and memcpy writes past the DMA buffer, causing memory corruption.

Add a len > halfkeysz check next to the existing !len check for each of the five CRT components so the driver falls back to the non-CRT path instead of writing out of bounds.

In the Linux kernel, the following vulnerability has been resolved:

xfrm: Check for underflow in xfrmstatemtu

Leo Lin reported OOB write issue in esp component:

xfrmstatemtu() returns u32 but performs its arithmetic in unsigned modulo-2^32 space using an attacker-influenced "headerlen + authsize + netadj" subtracted from a small "mtu" argument. A nobody user can install an IPv4 ESP tunnel SA with a large authentication key (XFRMAALGAUTHTRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc), configure a small interface MTU (68 bytes), and set XFRMATFCPAD to a large value. When a single UDP datagram is then sent through the tunnel, xfrmstatemtu() underflows to a near-2^32 value, and espoutput() consumes it as a signed int via:

padto = min(x->tfcpad, xfrmstatemtu(x, mtucached)) esp.tfclen = padto - skb->len (assigned to int)

esp.tfclen ends up negative (e.g. -207). It is sign-extended to sizet when passed to memset() inside espoutputfilltrailer(), producing a ~16 EB write of zeroes at skbtailpointer(skb). KASAN logs it as "Write of size 18446744073709551537 at addr ffff888...".

Check for underflow and return 1. This causes the sendmsg attempt to fail with ENETUNREACH.

In the Linux kernel, the following vulnerability has been resolved:

net: bridge: use a stable FDB dst snapshot in RCU readers

Local FDB entries can be rewritten in place by fdbdeletelocal(), which updates f->dst to another port or to NULL while keeping the entry alive. Several bridge RCU readers inspect f->dst, including brfdbfillbuf() through the brforwardread() sysfs path.

These readers currently load f->dst multiple times and can therefore observe inconsistent values across the check and later dereference. In brfdbfillbuf(), this means a concurrent local-FDB update can change f->dst after the NULL check and before the portno dereference, leading to a NULL-ptr-deref.

Fix this by taking a single READONCE() snapshot of f->dst in each affected RCU reader and using that snapshot for the rest of the access sequence. Also publish the in-place f->dst updates in fdbdeletelocal() with WRITEONCE() so the readers and writer use matching access patterns.